Distributed storage path configuration

ABSTRACT

Aspects of the present disclosure relate to transmitting prioritized path data to a device based on a set of topology rules and metrics associated with a storage target. A storage target path discovery request is received from the device. In response to the storage target path discovery request, metrics associated with the storage target are collected. Based on the collected metrics, available paths to the storage target are identified. A set of topology rules are then determined. Based on the topology rules and the collected metrics, a subset of available paths are selected. The subset of available paths are then prioritized into prioritized path data. The prioritized path data is then stored and transmitted to the device.

BACKGROUND

The present disclosure relates generally to the field of computing, andmore particularly to distributed computing environments.

The amount of data that needs to be organized by enterprises isincreasing. Accordingly, management of a shared pool of computingresources over a network can be desired to increase performanceefficiency. For example, storage area networks (SAN's) can be used toprovide access to block level data storage over a network. These systemscan ensure that computing nodes in a distributed computing environmentreceive the memory required to store the ever-increasing amount of dataassociated with the computing nodes. SAN's enhance computing nodes suchthat memory provided over the network appears to the operating system(OS) to be locally attached memory (e.g., hard drives).

SUMMARY

Embodiments of the present disclosure relate to transmitting prioritizedpath data to a device based on a set of topology rules and metricsassociated with a storage target. A storage target path discoveryrequest can be received from the device. In response to the storagetarget path discovery request, metrics associated with the storagetarget can be collected. Based on the collected metrics, available pathsto the storage target can be identified. A set of topology rules canthen be determined. Based on the topology rules and the collectedmetrics, a subset of available paths can be selected. The subset ofavailable paths can then be prioritized into prioritized path data. Theprioritized path data can then be stored and transmitted to the device.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included in the present disclosure are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent disclosure and, along with the description, serve to explain theprinciples of the disclosure. The drawings are only illustrative oftypical embodiments and do not limit the disclosure.

FIG. 1 is a block diagram of an example computing environment in whichillustrative embodiments of the present disclosure can be implemented.

FIG. 2 is a flow diagram illustrating a process for selecting andprioritizing target path data based on a set of topology rules, inaccordance with embodiments of the present disclosure.

FIG. 3A is a block diagram illustrating paths configured between adevice and a database, in accordance with embodiments of the presentdisclosure.

FIG. 3B is a diagram illustrating an example prioritization scheme forthe paths depicted in FIG. 3A, in accordance with embodiments of thepresent disclosure.

FIG. 3C is a diagram illustrating a cyclic buffer for Table 4 of FIG.3B, in accordance with embodiments of the present disclosure.

FIG. 4 is a high-level block diagram illustrating an example computersystem that can be used in implementing one or more of the methods,tools, and modules, and any related functions, described herein, inaccordance with embodiments of the present disclosure.

FIG. 5 is a diagram illustrating a cloud computing environment, inaccordance with embodiments of the present disclosure.

FIG. 6 is a block diagram illustrating abstraction model layers, inaccordance with embodiments of the present disclosure.

While the embodiments described herein are amenable to variousmodifications and alternative forms, specifics thereof have been shownby way of example in the drawings and will be described in detail. Itshould be understood, however, that the particular embodiments describedare not to be taken in a limiting sense. On the contrary, the intentionis to cover all modifications, equivalents, and alternatives fallingwithin the spirit and scope of the invention.

DETAILED DESCRIPTION

Aspects of the present disclosure relate generally to the field ofcomputing, and in particular to distributed computing environments.While the present disclosure is not necessarily limited to suchapplications, various aspects of the disclosure may be appreciatedthrough a discussion of various examples using this context.

Internet Small Computer Systems Interface (iSCSI) is an internetprotocol (IP) networking standard for storage system data transfer. Inthe iSCSI context, a path (e.g., iSCSI Transport) maps a client-serveriSCSI protocol to a specific interconnect. An initiator (e.g., iSCSIclient or host) is the start of the path and a target (e.g., iSCSIserver, storage resource, storage node, etc.) is the endpoint of thepath. An initiator begins the iSCSI communication by dispatching iSCSIcommands over the network. Specifically, initiators can first requestpossible paths from storage system(s) (e.g., which can include multipletargets) via an iSCSI discovery session. Upon receipt of the discoveryrequest (e.g., a “SendTargets” request) the storage system can return alist of all iSCSI paths available to the initiator to reach the targets.

After the list of iSCSI paths is received, the initiator can begin iSCSIlogin to the target ports and start transmitting input/outputs (I/Os)via the created paths, one port at a time. When transmitting I/O's,initiators can utilize several ports with respect to a predefinedscheduling algorithm (e.g., most recently used, round robin, fixed,etc.). The initiators can access the targets returned by the storagesystem in the order they are received via the “SendTargets” response.Thus, when providing the list of paths in response to the discoveryrequest, it can be beneficial to consider various metrics to determinethe order of paths returned to the initiator.

Various metrics can be considered when providing the list of paths tothe initiator. In some instances, network failure resiliency can beconsidered in order to provide a list of paths that ensures theinitiator has access to multiple network nodes (e.g., switches, hubs,bridges, routers, etc.). This ensures that, if any single network nodefails, the initiator can connect to a path with an operational networknode. The path data (e.g., path list, path table, etc.) can also beconfigured based on resource utilization. For example, the path data canbe configured to uniformly distribute workloads (e.g., bandwidthconsumption or processor utilization) across hardware components in thesystem. In some instances, storage node failure resiliency can beconsidered. This ensures that, if any single storage node (e.g., storagecontroller, server, etc.) fails, the initiator can connect to the targetvia an operational storage node. Further, port functionality (e.g.,ports that have a specified function) can be considered when providing alist of paths to the initiator. For example, ports used for resourceintensive tasks (e.g., mirroring or data migration) can be removed fromthe list or returned at the end of the list (e.g., to a position inwhich the port will be accessed last), to avoid relying on paths withports or storage nodes that have less available bandwidth.

Referring now to the figures, FIG. 1 is a block diagram illustrating anexample computing environment 100 in which illustrative embodiments canbe implemented. The computing environment 100 includes a storage node135 communicatively coupled to volumes 180-1, 180-2, 180-3 . . . 180-N(herein collectively referred to as volume 180). The storage node 135 isadditionally communicatively coupled to a plurality of devices 105-1,105-2 . . . 105-N (collectively referred to as device 105) via a network150.

Consistent with various embodiments, the storage node 135 and the device105 are computer systems. The device 105 and the storage node 135include one or more processors 115-1, 115-2 . . . 115-N (collectivelyprocessor 115) and 145 and one or more memories 120-1, 120-2 . . . 120-N(collectively memory 120) and 155, respectively. The device 105 and thestorage node 135 are configured to communicate with each other throughinternal or external network interfaces 110-1, 110-2 . . . 110-N(collectively network interface 110) and 140. The network interfaces 110and 140 are, in some embodiments, modems or network interface cards. Thedevice 105 and/or the storage node 135 can be equipped with a display ormonitor. Additionally, the device 105 and/or the storage node 135include optional input devices (e.g., a keyboard, mouse, scanner, videocamera, or other input device), and/or any commercially available orcustom software (e.g., browser software, communications software, serversoftware, natural language processing software, search engine and/or webcrawling software, filter modules for filtering content based uponpredefined parameters, etc.). The device 105 and/or the storage node 135can be servers, controllers, desktops, laptops, hand-held devices or anycombination thereof.

The device 105 and the storage node 135 can be distant from each otherand communicate over a network 150. In some embodiments, the storagenode 135 can be a central hub from which devices 105 can establish acommunication connection, such as in a client-server networking model.Alternatively, the storage node 135 and device 105 can be configured inany other suitable networking relationship (e.g., in a peer-to-peer(P2P) configuration or other network topology).

In some embodiments, the network 150 can be implemented using any numberof any suitable communications media. For example, the network 150 canbe a wide area network (WAN), a local area network (LAN), an internet,or an intranet. In certain embodiments, the device 105 and the storagenode 135 can be local to each other, and communicate via any appropriatelocal communication medium. For example, the device 105 and the storagenode 135 can communicate using a local area network (LAN), one or morehardwire connections, a wireless link or router, or an intranet. In someembodiments, the device 105 and the storage node 135 can becommunicatively coupled using a combination of one or more networksand/or one or more local connections. For example, the first device105-1 can be hardwired to the storage node 135 (e.g., connected with anEthernet cable) while the second device 105-2 can communicate with thestorage node 135 using the network 150 (e.g., over the Internet).Additionally, the storage node 135 can be communicatively coupled to thevolume 180 using the network 150. However, in some embodiments, thevolume 180 can be locally attached to the storage node 135.

In some embodiments, the network 150 is implemented within a cloudcomputing environment, or using one or more cloud computing services.Consistent with various embodiments, a cloud computing environment caninclude a network-based, distributed data processing system thatprovides one or more cloud computing services. Further, a cloudcomputing environment can include many computers (e.g., hundreds orthousands of computers or more) disposed within one or more data centersand configured to share resources over the network 150.

The storage node 135 includes a plurality of input/output (I/O) ports170-1, 170-2, 170-3 . . . 170-N (herein collectively referred to as I/Oport 170). The I/O ports 170 can be endpoint communication addresses(e.g., IP addresses) associated with the storage node 135. Specifically,the I/O port 170 allows the device 105 to interface the storage targets(e.g., volumes 180) via paths (e.g., network paths) over the network150.

Though a single storage node 135 is depicted in FIG. 1, in embodiments,any number of storage nodes 135 can be implemented. Further, eachstorage node can include any number of subunits (e.g., sub-nodes) andany number of I/O ports. For example, in some embodiments, computingenvironment 100 can include five storage nodes each including 20 I/Oports.

The storage nodes can be implemented in any manner. In the embodimentdepicted in FIG. 1, the storage node 135 is depicted as a server, havingits own hardware resources (e.g., processor 145 and memory 155).However, in embodiments, the storage node 135 can be a virtualizedpartition of a server (e.g., a virtual machine running on the server) ormachine. In some embodiments, the storage node 135 can include aplurality of servers and/or virtual machines. In some embodiments, thestorage node 135 can be a portion of hardware (e.g., a storagecontroller) located on a server. However, the storage node can beimplemented in any other manner otherwise consistent herein.

The volume 180 can include any suitable storage. In some embodiments,the volume 180 is structured into block storage. The volume 180 caninclude magnetic tape storage, NAND flash memory, floppy disks, harddisks, optical disks, and the like. In some embodiments, the storagevolume 180 can be remote and accessible over a storage area network(SAN) (e.g., via iSCSI or ATA over Ethernet (AoE) protocols). However,in some embodiments, the volume 180 can be directly attached andaccessible via SCSI or Fibre Channel.

The storage node 135 includes a topology management module 160. Thetopology management module 160 can be configured to receive a targetdiscovery requests (e.g., destination discovery requests) from thedevice 105 and provide target path data (e.g., path lists, path tables,etc.) to the device 105. Because the device 105 (e.g., initiators in aniSCSI environment) typically logs in to the target paths in the orderthey are received via the discovery response (e.g., “SendTargets”response), it can be beneficial to filter and prioritize the path dataprior to transmission to the device 105. Accordingly, the topologymanagement module 160 can analyze a variety of metrics (e.g., the numberof network nodes, the number of I/O nodes, the number of storage nodes,available storage, available bandwidth (per port or per node), processorutilization (per port or per node), etc.) associated with the storagenode 135 and use the metrics, along with configurable topology rules, toselectively filter and prioritize the list of paths to be returned tothe device 105.

The topology management module 160 can be configured to collect avariety of metrics in the system. The metrics collected by the topologymanagement module 160 can include identification of all paths configuredbetween the device 105 and storage node 135. The paths can include thenetwork topology logic which bridges the initiator to the target. Forexample, the paths can include the following logic format:(initiator→network node→I/O port). To identify the paths between thedevices 105 and volumes 180, the topology management module 160 can beconfigured to acquire all combinations of network nodes and I/O ports170 which allow each device 105 to access the volumes 180.

Further, the topology management module 160 can be configured todetermine a set of topology rules with respect to the list of identifiedpaths. The topology rules can dictate prioritization with respect to thelist of identified paths by taking into account various constraints,including network failure resiliency, node failure resiliency, portfunction, and resource utilization, to name a few. Based on the topologyrules, the topology management module 160 can select a subset of pathsand prioritize the selected subset of paths prior to transmission to thedevice 105. The device 105 can then perform log-in to the paths based onthe received path data from the topology management module 160.

In some embodiments, software defined networking (SDN) technologies canbe utilized to reconfigure the network topology as needed. This canallow the system to dynamically reconfigure network topology via rulesfor packet handling specified in computer readable code (e.g., a SDNapplication).

While FIG. 1 illustrates a computing environment 100 with a singlestorage node 135, suitable computing environments for implementingembodiments of this disclosure can include any number of storage nodes.The various models, modules, systems, and components illustrated in FIG.1 can exist, if at all, across a plurality of storage nodes and devices.For example, some embodiments can include three storage nodes. The threestorage nodes can be communicatively coupled using any suitablecommunications connection (e.g., using a WAN, a LAN, a wired connection,an intranet, or the Internet). Further, in some embodiments, thetopology management module 160 is included on one or more devices 105 orvolumes 180.

It is noted that FIG. 1 is intended to depict the representative majorcomponents of an example computing environment 100. In some embodiments,however, individual components can have greater or lesser complexitythan as represented in FIG. 1, components other than or in addition tothose shown in FIG. 1 can be present, and the number, type, andconfiguration of such components can vary.

FIG. 2 is a flow diagram illustrating a process 200 for selecting andprioritizing path data (e.g., a storage target path list) based on a setof topology rules, in accordance with embodiments of the presentdisclosure.

Process 200 begins by receiving a discovery request. This is illustratedat step 205. The discovery request queries a storage node (e.g., storagecontroller, server, virtual machine, etc.) receiving the request toprovide a list of possible paths (e.g., interfaces) that connect therequesting device (initiator) to the storage node (e.g., target). Assuch, receiving a discovery request initiates a path discovery process.In some embodiments, the discovery request is issued in an iSCSIprotocol. The discovery request can be initiated on a pull or pushbasis. For example, in some embodiments, a storage node (e.g., storagenode 135) can request a discovery request (e.g., on a pull basis). Insome embodiments, the device (e.g., device 105-1) can transmit thediscovery request (e.g., on a push basis).

The discovery request can be received in any manner. In someembodiments, the discovery request is received over a network (e.g.,network 150). In some embodiments, the discovery request is locallyinitiated (e.g., by a user). The discovery request can be associatedwith a specific machine. For example, a discovery request received froma device over a network can enable the receiving storage node todetermine the possible interfaces associated with the requestingmachine.

In some embodiments, upon receiving the discovery request, the entity(e.g., user or machine) transmitting the request can be authenticated.Authentication methods can include passwords, cryptographicauthentication, and biometric authentication, and others. Further, theauthentication can include a combination of protocols (e.g., two-factorauthentication or three-factor authentication).

Storage target metrics are then collected following the discoveryrequest. This is illustrated at step 210. Collecting storage metrics canallow the storage node receiving the request to analyze and identifyvarious metrics related to the storage targets. For example, topologydata can be collected. The topology data can indicate topology logicthat interfaces the device with the target storage. As such, topologydata can include specific network nodes (e.g., switches, hubs, bridges,etc.), storage nodes (e.g., servers or controllers) and/or I/O portsthat connect the requesting device to the storage resources. In someembodiments, resource utilization by each storage node and I/O port canbe collected. For example, processor utilization and bandwidth for eachstorage node or I/O port can be collected. In some embodiments,processor utilization can be collected via Task Manager or systemmonitor. In some embodiments, bandwidth can be determined via a speedtest. In some embodiments, I/O port function data can be collected. TheI/O port function data can indicate specific functions of individualports (e.g., ports used for migration, back-up, or mirroring). In someembodiments, topology data can be collected by a software definednetworking application. In some embodiments, geographic location datacan be collected such that the path data can be prioritized based onproximity or other geographic considerations. In some embodiments,historical error data associated with specific network nodes, storagenodes, and ports can be collected. The historical error data can includethe downtime of specific ports, storage nodes, and network nodesovertime (e.g., as a result of maintenance, crashes, etc.). However, anyother data associated with the storage system can be collected, and candepend on the sought path selection and prioritization.

After storage target metrics are collected, available target paths areidentified. This is illustrated at step 215. Based on the collectedtopology logic data, paths that interface the initiator to the storagetarget can be identified. The paths can be stored in a list, table, orany other format. In some embodiments, path data is dispatched to eachstorage node associated with the requesting device. The path data canthen be stored in local memory on each storage node. In someembodiments, the path data is stored in a database associated with eachstorage node.

A set of topology rules are then determined. This is illustrated at step220. A set of topology rules can be applied to selectively filter andprioritize the path data. The set of topology rules can be determined inany manner. In some embodiments, the set of topology rules are definedand provided to the system (e.g., manually by a user). In someembodiments, the set of topology rules are dynamically determined (e.g.,automatically determined by a computer system without user intervention)based on the collected storage target metrics. For example, the topologyrules can be automatically determined based on the observed number ofnetwork, storage nodes, the total number of identified paths, theresource utilization associated with each storage node, etc. The set oftopology rules can also depend on a configured I/O port schedulingalgorithm for each machine.

In some embodiments, the set of topology rules includes network failureresiliency rules. The network failure resiliency rules can provideresiliency to network node failures. This can ensure that the clientsmaintain communication with the storage resources in the event thatthere are network node failures (e.g., switches that lose power ormalfunction). The network failure resiliency rules can define athreshold number of network nodes required to be returned in the list ofpaths (e.g., the list must contain a minimum threshold value of fiveswitches). This can ensure that the initiator has access to a minimumnumber of network nodes at any particular time, which can reduce thelikelihood of a communication loss between the initiator and the storageresources. In some embodiments, the network failure resiliency rules canalso define a network failure resiliency prioritization scheme. Thenetwork failure resiliency prioritization scheme can define path orderbased on network node identifications (e.g., indicators that distinguishbetween particular network nodes). For example, if there are fourdifferent switches configured in paths included in the target path data,the scheme can be configured to interleave the paths containing thedifferent switches (e.g., order the paths with different network nodesin an alternating manner), such that if a single switch fails, the nextpath included in the path data contains a different network switch (formore detail, see FIG. 3B, Tables 2 and 3). The prioritization can ensurethat no two sequential paths included in the path data have the samenetwork node identification.

However, the network failure resiliency prioritization scheme can beconfigured in any other manner. For example, in some embodiments, thenetwork failure resiliency prioritization scheme can take intoconsideration the robustness of particular network nodes. The robustnessof particular network nodes can be determined manually, or alternativelybased on historical error data (e.g., how many packet forwarding errorsoccurred in the past, how many outages the network node had in the past,past maintenance, future maintenance, the overall downtime of thenetwork node per time metric, etc.). As such, the network failureresiliency scheme can prioritize paths based on the robustness ofparticular network nodes. As an example, if historical failure data iscollected for three network nodes “A”, “B”, and “C”, and their overalldowntime per month is 10 minutes, 20 seconds, and 1 hour, respectively,then the network failure resiliency scheme can assign network node “B”the highest priority, network node “A” intermediate priority, andnetwork node “C” the lowest priority.

Though unconventional path log-ins (e.g., log-ins to network nodes whichare not proximate to the initiator or ports which are not normallyaccessed) may result based on the network failure resiliency rules, theconnected initiators may have a higher likelihood of maintainingconnection with the target resources in the event of network nodefailures.

In some embodiments, the set of topology rules include storage nodefailure resiliency rules. The storage node failure resiliency rulesprovide resiliency to storage target connection failures in the eventthat storage node(s) in the system are unavailable (e.g., lose power,malfunction, are scheduled for maintenance, etc.). The storage nodefailure resiliency rules can be defined in substantially a similarmanner to the network node failure resiliency rules referenced above.For example, the storage node failure resiliency rules can define athreshold number of storage nodes required to be returned in the list ofpaths (e.g., the list must return a minimum number of storage nodes).This can ensure the initiator has availability to a minimum number ofstorage nodes in the event any storage node(s) are unavailable for anyreason. Similarly, the storage node failure resiliency rules can alsodefine a storage node failure resiliency prioritization scheme. In someembodiments, the storage node failure resiliency prioritization schemecan be defined to interleave paths containing different storage nodes.This can ensure that if a particular storage node fails, the initiatorwill connect to a path with a different storage node upon failure of thestorage node which the initiator was already connected to. Ultimately,storage node failure prioritization scheme can ensure that no twosequential paths included in the path data include the same storagenode.

Further, the storage node failure resiliency prioritization scheme canalso take into consideration the robustness of specific storage nodes.In some embodiments, the robustness of particular storage nodes can bedetermined based on historical failure data (e.g., server downtime,maintenance data, data corruptions, etc.). As an example, if historicalfailure data is collected for three storage nodes “A”, “B”, and “C”, andthe scheduled maintenance downtime annually is 1 week, 3 days, and 12hours, respectively, then the network failure resiliency scheme canassign network node “C” the highest priority, network node “B”intermediate priority, and network node “A” the lowest priority.

In some embodiments, the topology rules can include port function rules.Specific I/O ports associated with storage nodes can be used fordifferent functions (e.g., mirroring, migration, back-up, etc.).Accordingly, storage resource availability can depend heavily on theport function. The port function rules can define path selection andprioritization based on port function metrics. For example, if a givenport is used for data migration, the port can be returned at the end ofthe list (accessed by the initiator last) initially (or alternativelycan be removed from the port selection) to prevent the device frominterfacing a port used for data migration (which is likely to have lessavailable bandwidth). In some embodiments, the port function metric canbe numerically represented (e.g., by a fraction, integer, etc.). Forexample, a non-functional port (a port without a dedicated function) canbe assigned a port function metric of 0, while a dedicated functionalport can be assigned a port function metric of 1. In some embodiments,if certain ports are not entirely dedicated functional ports, they canbe given an intermediate port functional metric (e.g., following theexample above, 0.5). The ports can then be prioritized based on the portfunction metrics according to the port function rules. Following theexample above, the port without a dedicated function could be assignedthe highest priority (e.g., moved to the beginning of the path list suchthat it is accessed first) and the dedicated functional port could beassigned the lowest priority (e.g., moved to the end of the path listsuch that it is accessed last), while the intermediate functional portcould be assigned intermediate priority.

In some embodiments, the topology rules can include resource utilizationrules. The resource utilization rules can define path selection andprioritization based on available storage node computing resources. Insome embodiments, the resource utilization rules can define a list ofpaths to each client such that a particular resource (e.g., processorutilization or bandwidth) is uniformly utilized throughout the system.

For example, if four I/O ports, “A”, “B”, “C”, and “D” are available toa given initiator, and ports “A” and “C” have half of the availablebandwidth than ports “B” and “D” have, paths containing ports “A” and“C” can be returned at the end of the path list (e.g., and thus beaccessed last by the initiator). This can ensure that the paths withless available bandwidth are accessed by the initiator last, which couldreduce bottlenecks in low bandwidth paths and improve storage resourceretrieval.

As an example for available processor utilization, if three storagenodes “X”, “Y”, and “Z” have 25%, 40%, and 60% processor availabilityrespectively, paths including storage node “Z” can be issued highpriority, paths including storage node “Y” can be issued intermediatepriority, and paths including storage node “X” can be issued lowpriority. This can ensure that paths with low processor availability areaccessed last, such that any particular processor (e.g., or processorpartition) is not overburdened. The availability of any computerresource (e.g., CPU utilization, RAM availability, bandwidthavailability, etc.) can be considered in the resource utilization rules.

In some embodiments, the topology rules can specify geographic locationrules. The geographic location rules can define path prioritization andselection based on proximity to the initiator. Prioritizing pathscontaining path hardware (e.g., network and storage nodes) proximate tothe initiator can reduce latency and improve storage target retrieval.For example, if a three storage nodes “M”, “N” and “0”, are located inCalifornia, Wisconsin, and New York, respectively, and the initiatorthat issued the discovery request is located in Minnesota, then pathscontaining storage node “N” from Wisconsin can be issued high priority,as they are the closest to the initiator that issued the discoveryrequest. The paths containing storage nodes “M” and “0” could be thenissued lower priority (e.g., intermediate and low priority depending ontheir proximity to the initiator).

Further, the topology rules can specify hardware characteristic rules(e.g., the type or specifications of hardware included in the paths).This can allow paths that include hardware with higher performance orcompatibility to be prioritized higher in the path data. The hardwarecharacteristic rules can specify specific processor types (e.g.,manufacturers or architectures), memory types (e.g., solid state drivesvs. hard disk drives), and network hardware types (e.g., networkinterface cards, fiber optic cables, Ethernet, etc.).

In some embodiments, the topology rules can specify several rulessimultaneously. In these embodiments, the topology rules can be weighedor applied sequentially to the available paths in the system. Forexample, in some embodiments, node failure resiliency and networkfailure resiliency rules can be defined in the topology rules, and canbe applied to prioritize the path data (e.g., see FIG. 3B, Tables 3 and4). As another example, available processor utilization and bandwidthcan be considered simultaneously in the topology rules. In this example,three paths “A”, “B”, and “C” have available processor utilizationmetrics of 0.25, 0.50, and 0.75 respectively, and available bandwidthmetrics of 0.60, 0.40, and 0.20 respectively (e.g., based on normalizedvalues collected during step 210). If prioritization is completed solelybased on available processor utilization, the path order output (e.g.,from highest priority to lowest priority) would be: “C”, “B”, “A” (e.g.,0.75, 0.50, 0.25). Conversely, if prioritization is completed solely onavailable bandwidth, the order would be reversed to: “A”, “B”, “C”(0.60, 0.40, 0.20). If both processor utilization availability andbandwidth availability are simultaneously considered based on the sum ofthe available bandwidth and processing power with no weighted values,the prioritization order would be “C”, “B”, “A” (e.g., 0.95, 0.90,0.85). If, however, both processor and bandwidth availability aresimultaneously but with bandwidth availability having twice the weightas processor utilization availability, the output would be “A”, “B”, “C”(e.g., 1.45, 1.30, 1.15). Accordingly, the topology rules can beconfigurable based on weighted values.

After topology rules are defined, a subset of target paths is selected.This is illustrated at step 225. The subset of target paths is selectedaccording to the topology rules. For example, if the topology rulesspecify that 10 available paths are to be returned to the client, 10paths can be selected. The selected paths can depend on the appliedtopology rules (e.g., excluding paths with functional ports or lowresource utilization). In some embodiments, paths can be selected basedon one or more predefined thresholds specified in the topology rules.For example, paths can be selected to satisfy a minimum number ofnetwork nodes or storage nodes. In some embodiments, all paths areautomatically selected. However, paths can be selected in any othermanner otherwise consistent herein.

The subset of selected target paths is then prioritized (e.g., theselected path data is ordered). This is illustrated at step 230. Theselected target paths can be prioritized based on the topology rules.For example, the selected target paths can be prioritized based onnetwork failure resiliency rules (e.g., interleaving network nodes),storage failure resiliency rules (e.g., interleaving storage nodes),resource utilization rules (e.g., to uniformly utilize systemresources), or port function rules (e.g., to avoid ports with lowresource utilization based on port function). If a combination ofparameters is defined in the set of topology rules, the path data can beprioritized based on weighing the various rules or applying the specificmetrics in a predefined order.

The target path data is then transmitted to the initiator. This isillustrated at step 235. Transmitting the target paths at step 235 canbe completed in any manner. The target paths can be transmitted over anetwork (e.g., network 150) to the device requesting the discoverysession. In some embodiments, prior to transmitting the target paths,the target paths are stored in a database (e.g., on a storage nodeassociated with the paths). The target path transmission can include anindication that the path data discovery request was successfullyprocessed. Further, the transmission can include the topology rules usedto structure the path data. In some embodiments, the applied schedulingalgorithm (or a suggested scheduling algorithm) can be transmitted alongwith the path transmission.

A port log-in based on the path data may then be received, and the portlog-in is established (e.g., by the storage node). This is illustratedat step 240. The port log-in can include a request to access the firstprioritized path of the path data. However, in some embodiments, theport log-in request can include several paths on the list simultaneously(e.g., to connect to the storage target via two or more pathssimultaneously). The port log-in can also depend on a predefinedscheduling algorithm (e.g. fixed, round-robin, most recently used,etc.). After the applicable port log-in(s) are received, the storagenode establishes the connection by validating the port log-inrequest(s), thereby connecting the initiator to the storage system basedon the logged path(s). Validation can include any authenticationprotocols (e.g., passwords, biometric scanners, cryptographic methods,etc.).

The aforementioned steps may be completed in any order and are notlimited to those described. Additionally, some, all, or none of theaforementioned steps may be completed, while still remaining within thespirit and scope of the present disclosure. For example, in someembodiments, selecting target paths at step 225 is not completed. Insome embodiments, prioritization at step 230 can be completed prior toselection at step 225 (e.g., the ports can be prioritized and lowerpriority ports can be filtered during selection).

FIG. 3A is a block diagram illustrating paths configured between adevice 305 (e.g., device 105 of FIG. 1) and a database 370, inaccordance with embodiments of the present disclosure. FIG. 3Aillustrates the device 305 communicatively coupled to the database 370via two switches 310 and 315, eight ports 320, 325, 330, 335, 340, 345,350 and 355, and two storage nodes 360 and 365. As illustrated in FIG.3A, there are 16 possible paths from the device 305 to the database 370.Each path utilizes at least one switch, one port, and one storage node.Accordingly, each path can be denoted by (switch #, storage node #, port#, see FIG. 3B).

If the device 305 (e.g., the initiator) transmits a discovery request tothe database 370 (e.g., through storage node 360 or storage node 365),the list returned to the initiator may include each of the 16 paths (ifthe paths are not filtered). However, because the initiator typicallylogs into the ports in the order they are received, the path data can beprocessed (e.g., selectively filtered and prioritized based on topologyrules and observed metrics) prior to transmitting the path data to thedevice 305. Accordingly, the storage nodes 360 and 365 can be configuredto obtain metrics related to the overall system (e.g., the number ofnetwork nodes, the number of I/O ports, the number of storage nodes,available storage, available bandwidth, processor utilization, etc.),and use the metrics, along with configurable topology rules, toselectively filter and prioritize the paths prior to transmission to thedevice 305.

While FIG. 3A illustrates a computing environment with two storagenodes, two switches, and eight ports, suitable computing environmentsfor implementing embodiments of this disclosure can include any numberof storage nodes, switches, and ports. The various models, modules,systems, and components illustrated in FIG. 3A can exist, if at all,across a plurality of hardware components.

It is noted that FIG. 3A is intended to depict the representative majorcomponents of an example computing environment. In some embodiments,however, individual components can have greater or lesser complexitythan as represented in FIG. 3A, components other than or in addition tothose shown in FIG. 3A can be present, and the number, type, andconfiguration of such components can vary.

Referring now to FIG. 3B, shown is a diagram illustrating an exampleprioritization scheme for the 16 paths depicted in FIG. 3A, inaccordance with embodiments of the present disclosure. Theprioritization scheme depicted in FIG. 3B occurs in three sequentialstages: a port function prioritization stage, a network failureresiliency prioritization stage, and a storage node failure resiliencyprioritization stage. Prior to the port function prioritization stage,the system (e.g., storage nodes 360 and 365) collects metrics regardingthe initiator's (device 305) connection to the storage target (database370). Specifically, all paths connecting device 305 to the database 370are identified, along with all available network nodes, storage nodes,and ports.

Table 1 depicts an initial layout of the identified paths, with theirrespective switch number, storage node number, and port number. Theinitial path table may be configured in the order each path isdiscovered. The initial port list is then prioritized according totopology rules. The topology rules include each of the prioritizationstages depicted in FIG. 3B. Table 2 depicts the path table prioritizedaccording to a port function prioritization stage (the firstprioritization stage as indicated by the circled number). Ports 4 and 8(e.g., ports 335 and 355 in FIG. 3A) are ports dedicated to mirroring,and thus are likely to have less available bandwidth (or may have lessavailable bandwidth upon future mirroring). Accordingly, each pathincluding ports 4 and 8 is returned at the end of the list, as themirroring ports are the lowest priority paths according to the topologyrules. The network failure resiliency prioritization stage (the secondstage as indicated by the circled number) is then applied to ensure theclients connected to the storage system are resilient to network nodefailures. The network failure resilience prioritization scheme specifiesthat the two switches in the system must be interleaved such that if anygiven switch fails, the next scheduled path connection operates from theopposite network node. Because, in this embodiment, the path order inTable 2 already satisfied the network failure resilience scheme, nochanges occur from Table 2 to Table 3.

A storage node failure resiliency prioritization stage (the third stageas indicated by the circled number) is then applied to the path data ofTable 3. The storage node failure resiliency prioritization stageprioritizes the paths such that the storage nodes are accessible in analternating manner. However, in order to maintain satisfaction of theport function prioritization and network failure resilienceprioritization schemes, the node failure resiliency stage can only becompleted to a certain extent (e.g., with two instances of repeatednodes). However, in some embodiments, the node failure resiliencyprioritization scheme can be maintained at the expense of the otherprioritization schemes (e.g., based on weighting or differing thesequential order of the prioritization schemes) if it is not possible tosatisfy each scheme based on the topology rules.

The resulting path data of Table 4 provides network and storage nodefailure resiliency while limiting connection to functional ports. Theresulting path data is transmitted to device 350, and device 350 logsinto the paths based on the discovery response.

Though the prioritization scheme in FIG. 3B includes stages, any othermanner of prioritizing the path data can be completed. In someembodiments, multiple prioritization schemes are applied simultaneously.In some embodiments, only a single prioritization scheme may bespecified in the topology rules. In some embodiments, weighted valuescan be implemented to dictate the priority of each prioritization scheme(e.g., port functionality can be weighted higher than node failureresiliency). In some embodiments, the path data can be manuallyprioritized. However, any other manner of prioritizing the pathsotherwise consistent herein is contemplated.

Further, though the path data prioritization depicted in FIG. 3B isbased on port function, network failure resiliency, and node failureresilience, any other metrics can be considered. For example, in someembodiments, path prioritization can be based on available bandwidth,memory, or processor utilization. In some embodiments, theprioritization can take into account the port access schedulingalgorithm. In some embodiments, prioritization can consider proximity tohardware resources (e.g., server location, network node location, etc.).In some embodiments, ports can be prioritized based on the initiator'srequirements or tasks. In some embodiments, ports can be prioritizedbased on the type of hardware used (e.g., type of processors, types ofdata transfer cables (e.g., optical fibers, Ethernet, etc.)).

FIG. 3C is a diagram illustrating a cyclic buffer for the path data ofTable 4 from FIG. 3B, in accordance with embodiments of the presentdisclosure. The path data can be offset upon additional host connectionsto prevent excess connections to the same port, storage node, or switch.If multiple hosts connect to the configured path data in the same order,performance can be impeded by overburdening resources associated withthe high priority paths. Accordingly, offsetting the paths such that thehosts connect to different paths (e.g., or such that resourceutilization is uniform) can be beneficial.

For example, if a first host issues a discovery request and receives thepath list according to FIG. 3C (e.g., the prioritized path data), thelog-in will initiate at path 1. If a second host connects via the samepath list at a later time, the list will be reordered, starting withpath 5 (the offset is 4), generating an offset path data. The secondhost's path list will then end at path 12 (at which point the list willrestart at path 5), while the first host's path list ends at path 16 (atwhich point the list will restart at path 1). For each additional hostconnection, the path list can be reordered based on the determinedoffset.

The offset can be determined based on a range of factors. In someembodiments, the offset can be based on the number of paths and thenumber of connected hosts. For example, if there are 16 available pathsand four connected hosts, the offset can be determined by diving thenumber of paths by the number of connected hosts (e.g., 16 paths/4hosts=4 offset). In some embodiments, the offset can be determined whileconsidering port function metrics. In these embodiments, the offset canbe determined to avoid functional ports upon new host connections. Insome embodiments, the offset can be determined based on the proximity ofthe host to resources in a given path. In some embodiments, the offsetcan be determined manually. In some embodiments, the offset can dependon sought network nodes, storage nodes, or I/O ports. In someembodiments, the offset can depend on the scheduling algorithm in whichthe hosts are accessing the ports (e.g., if the scheduling algorithmspecifies alternation between two I/O ports, the offset can bedetermined to be 2 paths).

Referring now to FIG. 4, shown is a high-level block diagram of anexample computer system 401 (e.g., devices 105, 305 and storage nodes135, 360, 365) that may be used in implementing one or more of themethods, tools, and modules, and any related functions, described herein(e.g., using one or more processor circuits or computer processors ofthe computer), in accordance with embodiments of the present disclosure.In some embodiments, the major components of the computer system 401 maycomprise one or more CPUs 402, a memory subsystem 404, a terminalinterface 412, a storage interface 414, an I/O (Input/Output) deviceinterface 416, and a network interface 418, all of which may becommunicatively coupled, directly or indirectly, for inter-componentcommunication via a memory bus 403, an I/O bus 408, and an I/O businterface unit 410.

The computer system 401 may contain one or more general-purposeprogrammable central processing units (CPUs) 402A, 402B, 402C, and 402D,herein generically referred to as the CPU 402. In some embodiments, thecomputer system 401 may contain multiple processors typical of arelatively large system; however, in other embodiments the computersystem 401 may alternatively be a single CPU system. Each CPU 402 mayexecute instructions stored in the memory subsystem 404 and may includeone or more levels of on-board cache.

System memory 404 may include computer system readable media in the formof volatile memory, such as random access memory (RAM) 422 or cachememory 424. Computer system 401 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 426 can be provided forreading from and writing to a non-removable, non-volatile magneticmedia, such as a “hard-drive.” Although not shown, a magnetic disk drivefor reading from and writing to a removable, non-volatile magnetic disk(e.g., a “USB thumb drive” or “floppy disk”), or an optical disk drivefor reading from or writing to a removable, non-volatile optical discsuch as a CD-ROM, DVD-ROM or other optical media can be provided. Inaddition, memory 404 can include flash memory, e.g., a flash memorystick drive or a flash drive. Memory devices can be connected to memorybus 403 by one or more data media interfaces. The memory 404 may includeat least one program product having a set (e.g., at least one) ofprogram modules that are configured to carry out the functions ofvarious embodiments.

One or more programs/utilities 428, each having at least one set ofprogram modules 430 may be stored in memory 404. The programs/utilities428 may include a hypervisor (also referred to as a virtual machinemonitor), one or more operating systems, one or more applicationprograms, other program modules, and program data. Each of the operatingsystems, one or more application programs, other program modules, andprogram data or some combination thereof, may include an implementationof a networking environment. Programs 428 and/or program modules 430generally perform the functions or methodologies of various embodiments.

In some embodiments, the program modules 430 of the computer system 401include a topology management module. The topology management module maybe configured to receive discovery requests and collect topology datarelevant to the requestor. Further, the topology management module canbe configured to identify all available paths for the requesting client,and selectively filter and prioritize the list of paths based on a setof topology rules.

Although the memory bus 403 is shown in FIG. 4 as a single bus structureproviding a direct communication path among the CPUs 402, the memorysubsystem 404, and the I/O bus interface 410, the memory bus 403 may, insome embodiments, include multiple different buses or communicationpaths, which may be arranged in any of various forms, such aspoint-to-point links in hierarchical, star or web configurations,multiple hierarchical buses, parallel and redundant paths, or any otherappropriate type of configuration. Furthermore, while the I/O businterface 410 and the I/O bus 408 are shown as single respective units,the computer system 401 may, in some embodiments, contain multiple I/Obus interface units 410, multiple I/O buses 408, or both. Further, whilemultiple I/O interface units are shown, which separate the I/O bus 408from various communications paths running to the various I/O devices, inother embodiments some or all of the I/O devices may be connecteddirectly to one or more system I/O buses.

In some embodiments, the computer system 401 may be a multi-usermainframe computer system, a single-user system, or a server computer orsimilar device that has little or no direct user interface, but receivesrequests from other computer systems (clients). Further, in someembodiments, the computer system 401 may be implemented as a desktopcomputer, portable computer, laptop or notebook computer, tabletcomputer, pocket computer, telephone, smart phone, network switches orrouters, or any other appropriate type of electronic device.

It is noted that FIG. 4 is intended to depict the representative majorcomponents of an exemplary computer system 401. In some embodiments,however, individual components may have greater or lesser complexitythan as represented in FIG. 4, components other than or in addition tothose shown in FIG. 4 may be present, and the number, type, andconfiguration of such components may vary.

It is to be understood that although this disclosure includes a detaileddescription on cloud computing, implementation of the teachings recitedherein are not limited to a cloud computing environment. Rather,embodiments of the present disclosure are capable of being implementedin conjunction with any other type of computing environment now known orlater developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model can includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but can be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported, providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It can be managed by the organization or a third party andcan exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It can be managed by the organizations or a third partyand can exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure that includes anetwork of interconnected nodes.

Referring now to FIG. 5, illustrative cloud computing environment 510 isdepicted. As shown, cloud computing environment 510 includes one or morecloud computing nodes 500 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 500A, desktop computer 500B (e.g., devices 105,305 and storage nodes 135, 360, 365) laptop computer 500C (e.g., devices105, 305 and storage nodes 135, 360, 365), and/or automobile computersystem 500N can communicate. Nodes 500 can communicate with one another.They can be grouped (not shown) physically or virtually, in one or morenetworks, such as Private, Community, Public, or Hybrid clouds asdescribed hereinabove, or a combination thereof. This allows cloudcomputing environment 510 to offer infrastructure, platforms and/orsoftware as services for which a cloud consumer does not need tomaintain resources on a local computing device. It is understood thatthe types of computing devices 500A-N shown in FIG. 5 are intended to beillustrative only and that computing nodes 500 and cloud computingenvironment 510 can communicate with any type of computerized deviceover any type of network and/or network addressable connection (e.g.,using a web browser).

Referring now to FIG. 6, a set of functional abstraction layers providedby cloud computing environment 510 (FIG. 5) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 6 are intended to be illustrative only and embodiments of thedisclosure are not limited thereto. As depicted below, the followinglayers and corresponding functions are provided.

Hardware and software layer 600 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 602;RISC (Reduced Instruction Set Computer) architecture based servers 604;servers 606; blade servers 608; storage devices 610; and networks andnetworking components 612. In some embodiments, software componentsinclude network application server software 614 and database software616.

Virtualization layer 620 provides an abstraction layer from which thefollowing examples of virtual entities can be provided: virtual servers622; virtual storage 624; virtual networks 626, including virtualprivate networks; virtual applications and operating systems 628; andvirtual clients 630.

In one example, management layer 640 can provide the functions describedbelow. Resource provisioning 642 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. For example, resourceprovisioning 642 can allocate additional computing resources to devices(e.g., devices 105, 305) which are indicated to have high activity.Metering and Pricing 644 provide cost tracking as resources are utilizedwithin the cloud computing environment, and billing or invoicing forconsumption of these resources. In one example, these resources caninclude application software licenses. In some embodiments, Metering andPricing 644 indicates the number of allotted licenses to machines (e.g.,devices 105, 305 and storage nodes 135, 360, 365) in the system.Security provides identity verification for cloud consumers and tasks,as well as protection for data and other resources. User portal 646provides access to the cloud computing environment for consumers andsystem administrators. Service level management 648 provides cloudcomputing resource allocation and management such that required servicelevels are met. Service Level Agreement (SLA) planning and fulfillment650 provide pre-arrangement for, and procurement of, cloud computingresources for which a future requirement is anticipated in accordancewith an SLA.

Workloads layer 660 provides examples of functionality for which thecloud computing environment can be utilized. Examples of workloads andfunctions which can be provided from this layer include: mapping andnavigation 662; software development and lifecycle management 664;virtual classroom education delivery 666; data analytics processing 668;transaction processing 670; and identifying an identifiable media 672.

As discussed in more detail herein, it is contemplated that some or allof the operations of some of the embodiments of methods described hereinmay be performed in alternative orders or may not be performed at all,insofar as they are consistent herein; furthermore, multiple operationsmay occur at the same time or as an internal part of a larger process.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers, and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the variousembodiments. As used herein, the singular forms “a,” “an,” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“includes” and/or “including,” when used in this specification, specifythe presence of the stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. In the previous detaileddescription of example embodiments of the various embodiments, referencewas made to the accompanying drawings (where like numbers represent likeelements), which form a part hereof, and in which is shown by way ofillustration specific example embodiments in which the variousembodiments may be practiced. These embodiments were described insufficient detail to enable those skilled in the art to practice theembodiments, but other embodiments may be used and logical, mechanical,electrical, and other changes may be made without departing from thescope of the various embodiments. In the previous description, numerousspecific details were set forth to provide a thorough understanding thevarious embodiments. But, the various embodiments may be practicedwithout these specific details. In other instances, well-known circuits,structures, and techniques have not been shown in detail in order not toobscure embodiments.

Different instances of the word “embodiment” as used within thisspecification do not necessarily refer to the same embodiment, but theymay. Any data and data structures illustrated or described herein areexamples only, and in other embodiments, different amounts of data,types of data, fields, numbers and types of fields, field names, numbersand types of rows, records, entries, or organizations of data may beused. In addition, any data may be combined with logic, so that aseparate data structure may not be necessary. The previous detaileddescription is, therefore, not to be taken in a limiting sense.

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

Although the present invention has been described in terms of specificembodiments, it is anticipated that alterations and modification thereofwill become apparent to the skilled in the art. Therefore, it isintended that the following claims be interpreted as covering all suchalterations and modifications as fall within the true spirit and scopeof the invention.

What is claimed is:
 1. A method comprising: receiving, from a device, astorage target path discovery request; collecting, in response to thestorage target path discovery request, metrics associated with a storagetarget; identifying, based on the collected metrics, available paths tothe storage target; determining a set of topology rules, whereindetermining the set of topology rules further comprises determining athreshold minimum number of storage nodes; selecting, based on thetopology rules and the collected metrics, a subset of the availablepaths, wherein paths in the subset of available paths are selected toinclude at least the threshold number of storage nodes; prioritizing,based on the topology rules and the collected metrics, the subset of theavailable paths into a prioritized path data, wherein prioritizingincludes ordering the subset of available paths according to thetopology rules; storing the prioritized path data; and transmitting theprioritized path data to the device.
 2. The method of claim 1, furthercomprising: receiving a port log-in request for a port of at least oneof the paths included in the prioritized path data; and establishing aconnection for the at least one port log-in request.
 3. The method ofclaim 1, further comprising; receiving, from a second device, a secondstorage target path discovery request; determining, in response to thesecond storage target path discovery request, an offset from theprioritized path data; reordering, based on the determined offset, theprioritized path data to generate an offset path data; and transmittingthe offset path data to the second device.
 4. The method of claim 3,further comprising: receiving a port log-in request for a port of afirst path on the offset path data; and establishing a connection of thesecond device to the first path.
 5. The method of claim 1, wherein thesubset of available paths is prioritized such that paths containing asame network node do not sequentially repeat in the prioritized pathdata.
 6. The method of claim 1, wherein the subset of available paths isprioritized to interleave each storage node of the subset of availablepaths such that paths containing a same storage node do not sequentiallyrepeat in the prioritized path data.
 7. The method of claim 1, whereincollecting metrics of the storage target includes obtaining a processorutilization metric for each path of the available paths, wherein thesubset of available paths are prioritized based on the processorutilization metric for each path.
 8. The method of claim 1, whereincollecting metrics of the storage target includes determining a portfunction metric associated with each port at an endpoint of eachavailable path, wherein the subset of available paths are prioritizedbased on the port function metric for each path.
 9. A system comprising:a device; a storage target; at least one memory component; at least oneprocessor; and a topology management module configured to perform amethod comprising; receiving, from the device, a storage target pathdiscovery request; collecting, in response to the storage target pathdiscovery request, metrics associated with the storage target;identifying, based on the collected metrics, available paths to thestorage target; determining a set of topology rules, wherein determiningthe set of topology rules further comprises determining a thresholdminimum number of storage nodes; selecting, based on the topology rulesand the collected metrics, a subset of the available paths, whereinpaths in the subset of available paths are selected based on the pathsin the subset including at least the threshold minimum number of storagenodes; prioritizing, based on the topology rules and the collectedmetrics, the subset of the available paths into a prioritized path data,wherein prioritizing includes ordering the subset of available pathsaccording to the topology rules; storing the prioritized path data;transmitting the prioritized path data to the device; receiving a portlog-in request to a port of the storage target for at least one of thepaths included in the prioritized path data; and establishing aconnection for the at least one port log-in request.
 10. The system ofclaim 9, wherein the system further comprises a second device, whereinthe method performed by the processor further comprises: receiving, fromthe second device, a second storage target path discovery request;determining, in response to the second storage target path discoveryrequest, an offset from the prioritized path data; reordering, based onthe determined offset, the prioritized path data to generate an offsetpath data; transmitting the offset path data to the second device;receiving a port log-in request to a first path on the offset path data;and establishing a connection of the second device to the first path.11. The system of claim 9, wherein determining the set of topology rulesfurther comprises determining a threshold number of paths to be includedin the prioritized path data, wherein the subset of available paths isselected based on the threshold number of paths.
 12. The system of claim9, wherein the subset of available paths is prioritized such that pathscontaining a same network node do not sequentially repeat in theprioritized path data.
 13. The system of claim 9, wherein the subset ofavailable paths is prioritized to interleave each storage node of thesubset of available paths such that paths containing a same storage nodedo not sequentially repeat in the prioritized path data.
 14. The systemof claim 9, wherein collecting metrics of the storage target includesobtaining a bandwidth availability metric for each path of the availablepaths, wherein the subset of available paths are prioritized based onthe bandwidth availability metric for each path.
 15. The system of claim9, wherein collecting metrics of the storage target includes determininga port function metric associated with each port at an endpoint of eachavailable path, wherein the subset of available paths are prioritizedbased on the port function metric for each path.
 16. A computer programproduct comprising a computer readable storage medium having programinstructions embodied therewith, the program instructions executable bya processor to cause the processor to perform a method comprising:receiving, from a device, a storage target path discovery request;collecting, in response to the storage target path discovery request,metrics associated with a storage target; identifying, based on thecollected metrics, available paths to the storage target; determining aset of topology rules, wherein determining the set of topology rulesfurther comprises determining a threshold minimum number of storagenodes; selecting, based on the topology rules and the collected metrics,a subset of the available paths, wherein paths in the subset ofavailable paths are selected based on the paths in the subset includingat least the threshold minimum number of storage nodes; prioritizing,based on the topology rules and the collected metrics, the subset of theavailable paths into a prioritized path data, wherein prioritizingincludes ordering the subset of available paths according to thetopology rules; storing the prioritized path data; transmitting theprioritized path data to the device; receiving a port log-in request toa port of the storage target for at least one of the paths included inthe prioritized path data; and establishing a connection for the atleast one port log-in request.
 17. The computer program product of claim16, wherein the method further comprises: receiving, from a seconddevice, a second storage target path discovery request; determining, inresponse to the second storage target path discovery request, an offsetfrom the prioritized path data; reordering, based on the determinedoffset, the prioritized path data to generate an offset path data;transmitting the offset path data to the second device; receiving a portlog-in request to a first path on the offset path data; and establishinga connection of the second device to the first path.
 18. The computerprogram product of claim 16, wherein collecting metrics of the storagetarget includes determining a processor utilization availability metricand a bandwidth availability metric of each path, wherein the processorutilization availability metric and bandwidth availability metric areweighted and combined to generate a resource availability metric,wherein the subset of available paths are prioritized based on theresource availability metric.